Description

Adds a --body-file <PATH> argument that loads the changelog body template from a file, as an alternative to the inline --body <TEMPLATE> argument.

• New CLI argument: --body-file <PATH> (also configurable via the GIT_CLIFF_TEMPLATE_FILE environment variable).
• The path supports tilde (~) expansion via the existing Opt::parse_dir helper, consistent with --from-context and other path arguments.
• --body and --body-file are marked conflicts_with so only one may be set at a time.
• Documentation updated in website/docs/usage/args.md and website/docs/usage/examples.md. The man page and shell completions pick up the new argument automatically from the clap definition.

Motivation and Context

Passing a multiline template inline via --body "$(cat template.tera)" breaks on newlines, as reported in #1558. Templates often start with directives like {% raw %}, which makes the breakage particularly confusing. A dedicated --body-file argument lets users keep their template in a file:

git cliff --body-file template.tera

Closes #1558

How Has This Been Tested?

• cargo build -p git-cliff clean
• cargo test -p git-cliff --lib all 7 tests pass, including two new ones:
  • body_file_is_parsed_as_path verifies --body-file parses into a PathBuf and does not set body
  • body_and_body_file_conflict verifies clap rejects setting both flags with ArgumentConflict
• cargo clippy -p git-cliff --tests -- -D warnings no warnings
• cargo +nightly fmt --all -- --check clean
• End-to-end: ran the built binary with a multiline template.tera starting with {% raw %} and confirmed the full file content was loaded into the changelog template (the case the issue reports as broken). The conflict check also fires at the CLI: passing both --body and --body-file exits with error: the argument '--body <TEMPLATE>' cannot be used with '--body-file <PATH>'.

Types of Changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation (no code change)
• Refactor (refactoring production code)
• Other

Checklist:

• My code follows the code style of this project.
• I have updated the documentation accordingly (if applicable).
• I have formatted the code with rustfmt.
  • cargo +nightly fmt --all
• I checked the lints with clippy.
  • cargo clippy --tests --verbose -- -D warnings
• I have added tests to cover my changes.
• All new and existing tests passed.
  • cargo test